home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-iplpdn-simple-multi-01.txt
< prev
next >
Wrap
Text File
|
1993-09-02
|
27KB
|
809 lines
Draft Internet Multilink August 1993
INTERNET DRAFT
Expires: February 15th, 1994
A Multilink Protocol for Synchronizing
the Transmission of Multi-protocol Datagrams.
Keith Sklower
Computer Science Department
University of California, Berkeley
1. Status of This Memo
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of
six months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not appro-
priate to use Internet Drafts as reference material or to
cite them other than as a ``working draft'' or ``work in
progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil,
nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au to learn the current status of any Internet
Draft.
2. Abstract
This document proposes a method for splitting and recombin-
ing datagrams across multiple logical data links. Such
facilities are desirable to exploit the potential for
increased bandwidth offered by multiple bearer channels in
ISDN, yet to do so in such away that minimizes reordering of
packets. This is accomplished by means of new PPP [2]
options and protocols.
This draft incorporates comments arising at the 27th IETF
meeting in Amsterdam.
Sklower [Page 1]
Draft Internet Multilink August 1993
3. Acknowledgements
The author specifically wishes to thank Brian Lloyd of Lloyd
& Associates, Fred Baker of ACC, Craig Fox of Network Sys-
tems, Gerry Meyer of Spider Systems, Dave Carr of Gandalf,
Tom Coradetti of Digiboard, and the members of the IP over
Large Public Data Networks and PPP extensions working
groups, for much useful discussion on the subject.
4. Conventions
The following language conventions are used in the items of
specification in this document:
o MUST, SHALL or MANDATORY -- the item is an absolute
requirement of the specification.
o SHOULD or RECOMMENDED -- the item should generally be
followed for all but exceptional circumstances.
o MAY or OPTIONAL -- the item is truly optional and may
be followed or ignored according to the needs of the
implementor.
5. Introduction
Basic Rate and Primary Rate ISDN both offer the possibility
of opening multiple simultaneous channels between systems,
giving users additional bandwidth on demand (for additional
cost). Previous proposals for the transmission of internet
protocols over ISDN have stated as a goal the ability to
make use of this capability, (e.g. Leifer et al. [1]).
There are proposals being advanced by communications
providers for providing synchronization between multiple
streams at the bit level (the BONDING proposals); such fea-
tures are not as yet widely deployed, and may require addi-
tional hardware for end system. Thus, it may be useful to
have a purely software solution, or at least an interim mea-
sure.
Furthermore, even if the ISDN service providers guarantee
bit-synchronization between different switched circuits,
there may not be sufficiently flexible hardware in a partic-
ular end system to combine the multiple bit streams in arbi-
trary orders for HDLC bit-unstuffing.
There are other instances where bandwidth on demand can be
exploited, such as opening additional X.25 SVC where the
window size is limited to two by international agreement.
The simplest possible algorithms of alternating packets
between channels on a space available basis (which might be
Sklower [Page 2]
Draft Internet Multilink August 1993
called the Bank Teller's algorithm) may have undesirable
side effects due to reordering of packets.
By means of a two-byte sequencing header, and simple syn-
chronization rules, one can split packets among parallel
virtual circuits between systems in such a way that packets
do not become reordered, or at least the likelihood of this
is greatly reduced.
The method discussed here is similar to the multilink proto-
col described in ISO 7776, but offers the additional ability
to split and recombine packets, thereby reducing latency.
Furthermore, there is no requirement here for acknowledged-
mode operation on the link layer, although that is option-
ally permitted.
Any method for bandwidth aggregation would require some
means of identifying which channels are to participate in
such a process. This could be achieved specifically in the
case of ISDN by use of the calling party information ele-
ment, but more generally by using PPP's authentication pro-
tocols [3]. For Frame Relay run over dedicated channels
some sort of manual configuration could suffice. For X.25,
the X.121 call request source address might alternatively be
used.
In order to use the multilink protocol in Frame Relay, and
X.25 environments, one uses the encodings for PPP, which
have been described elsewhere in a way compatible with RFC's
1294 and 1356.
6. General Overview
The Point-to-Point Protocol (PPP) provides a standard method
of encapsulating Network Layer protocol information over
(virtual) point-to-point links.
PPP has four main components:
1. A method for encapsulating datagrams over serial links.
2. A Link Control Protocol (LCP) for establishing, config-
uring, and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for estab-
lishing and configuring different network-layer proto-
cols.
4. A family of Network-Layer Protocols (NPs) which are the
classes of data to be transmitted themselves.
In order to establish communications over a point-to-point
link, each end of the PPP link must first send LCP packets
Sklower [Page 3]
Draft Internet Multilink August 1993
to configure the data link during Link Establishment phase.
After the link has been established, PPP provides for an
Authentication phase before proceeding to the Network-Layer
Protocol phase. Since the idea is to ``tie together'' mul-
tiple circuits between a fixed pair of systems, and since
both of the current PPP authentication protocols permit the
side effect of assigning identifiers to both systems, it
makes sense to exploit the use of one or the other of the
existing authentication protocols (or any future authentica-
tion protocol that assigns unique identifiers to communicat-
ing systems), rather than introducing a separate mechanism
for naming multilink groups.
We suggest that multilink operation can be modeled as a sep-
arate PPP Network-Layer protocol (which we'll call the Mul-
tilink Protocol, or MP) with its own control protocol (the
Multilink Control Protocol, or MCP), which may be negotiated
in the usual PPP manner. A slightly unusual convention (for
PPP) might be to identify reconstituted packets as being
transmitted over a separate logical link (which we'll call
the bundle) which is distinct from the constituent physical
links (which we'll call the member links).
Thus, if the (PPP) Multilink (network-layer) Protocol were
proposed and accepted in both directions on a physical link
between two systems that had previously concluded negotiat-
ing all network protocols to be carried over the bundle
(group link) via another physical circuit, and all traffic
sent over the new (member) link were encapsulated with mul-
tilink headers, no additional negotiation would be required
on the new link.
Any changes to the state of the bundle from the default
state MUST be made by encapsulating LCP or NCP packets
inside Multilink Protocol packets. (I.e. by placing LCP or
NCP packet headers after the multilink headers). However,
we believe that it should almost never be necessary to re-
negotiate the set of LCP-level defaults proposed for the
bundle.
Work is in progress on alternative means for memorizing the
state of concluded negotations and re-invoking that state.
7. Packet Formats
Fragments may be thought of as packets in a separate PPP
protocol. Large packets are first encapsulated according to
normal PPP procedures, and then are broken up into multiple
frames sized appropriately for the multiple physical links.
A new PPP header consisting of the Multilink Protocol Iden-
tifier, and the Multilink header is inserted before each
section. (Thus the first fragment of a multilink packet in
PPP will have two headers, one for the fragment, followed by
Sklower [Page 4]
Draft Internet Multilink August 1993
the header for the packet itself).
PPP multilink fragments are encapsulated using the protocol
identifier 0x00-0x3d, followed by a two byte header giving a
sequence number, Beginning Fragment of Packet bit, and End-
ing Packet of Fragment bit. Unless Address & Control and
Protocol ID compression are in effect, individual fragments
will, therefore, have the following format:
Sklower [Page 5]
Draft Internet Multilink August 1993
Figure 1: Fragment Format.
+---------------+---------------+
| Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-------+---------------+
|B|E|0|0| sequence number |
+-+-+-+-+-------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
| FCS |
+---------------+---------------+
The sequence field is a 12 bit number that is incremented
every for every fragment transmitted.
The (B)eginning fragment bit is a one bit field set to 1 on
the first fragment and set to 0 for all other fragments.
The (E)nding fragment bit is a one bit field set to 1 on the
last fragment and set to 0 for all other fragments.
The reserved field is 2 bits long and is not currently
defined. It must be set to 0.
In this multilink protocol, a separate and single reassembly
structure is associated with each pair of authenticated
entities. The multilink headers are interpreted in the con-
text of this structure. It is permissible for a fragment to
have both the (B)eginning and (E)ending fragment bits set.
Two systems may implement multiple multilink groups by
responding to multiple authentication identifiers, one for
each group.
8. Trading Buffer Space Against Fragment Loss
In a multilink procedure, where one channel may be delayed
with respect to the other channel, fragments are may not
arrive in the same sequence they left the sender. So, it is
more difficult to determine that a fragment has been lost,
and more difficult to estimate the amount of buffer space
required. In this section we present a default strategy for
minimizing the buffer space required for retaining enough
fragments to determine that a fragment has been lost.
The idea is that the receiver should keep track of the mini-
mum of the sequence numbers of all fragments received on all
Sklower [Page 6]
Draft Internet Multilink August 1993
channels participating in the multilink procedure. (Call
this M). We require that the senders MUST transmit frag-
ments with increasing sequence numbers over any member link
in a bundle. Thus, every time M advances past a fragment
bearing an (E)nding bit that hasn't otherwise been reassem-
bled and sent, one can discard all fragments with sequence
number less than M, since any missing fragments will never
arrive on any link due to the increasing sequence number
rule.
In the case that the last fragment transmitted over a member
link before the link queue drains and the packet gets lost,
the receiver will stall until new packets arrive. The
sender may transmit a null fragment increasing the sequence
number for each channel when the queue for each physical
link becomes empty to attempt to reduce the likelyhood of
this. The receive should implement some kind of idle/dead -
link timer to resolve such cases.
The amount of buffering required to guarantee correct recog-
nition of fragment lost depends on the relative delay
between the channels (D[c1,c2]), the number of channels par-
ticipating (say N), the data rate of each channel R[c], the
fragment size (F) and the maximum permissible reassembled
size (P). When using PPP, the delay between channels can be
determined by LCP echo request and echo reply packets.
In the common case where the data rates are the same, one
could define for each channel, its slippage to be the band-
width times the delay for that channel relative to the slow-
est, S[c] = R[c] * D[c, c-worst]. Given these conditions
having buffer space of N*(P-F) + S[1] + S[2] + ... + S[n]
should be sufficient to insure that you have not have erro-
neously thrown away an incomplete packet before its complet-
ing fragment arrives.
9. Multilink Control Protocol
[Here, we shamelessly plagiarize RFC1220]
The Multilink Control Protocol is responsible for establish-
ing agreement to initiate multilink operation, and for set-
ting a limited number of parameters. It is exactly the same
as the Point-to-Point Link Control Protocol [2], with the
following exceptions:
Data Link Layer Protocol Field
Exactly one Multilink Control Protocol packet is encap-
sulated in the Information field of PPP Data Link Layer
frames where the Protocol field indicates type hex
803d.
Code field
Only Codes 1 through 7 (Configure-Request, Configure-
Sklower [Page 7]
Draft Internet Multilink August 1993
Ack, Configure-Nak, Configure-Reject, Terminate-
Request, Terminate-Ack and Code-Reject are used. Other
Codes should be treated as unrecognized and should
result in Code-Rejects.
Precedence
MCP packets may not be exchanged until the Link Control
Protocol has reached the network-layer protocol config-
uration negotiation phase, i.e. when link negotiation
has concluded, and after any use of the Authentication
Protocol. Systems implementing the Multilink Protocol
MAY omit the use of the Authentication when trusted
out-of-band identification is available, such as the
presence of X.121 or E.164 addresses or when the opera-
tion is conducted over leased lines.
Network Control packets may also be exchanged over a
member link concurrently with the exchange of Multilink
Control Packets, however such exchanges pertain ONLY to
the member links and not the bundle.
NCP packets pertaining to the operation of the bundle
MUST NOT be sent until the Multilink control exchange
has concluded, and then MUST be transmitted inside mul-
tilink packets (i.e. with the NCP headers following the
multilink headers). This is discussed below in the
section ``Interaction with Other Protocols.''
Configuration Option Types
The Multilink Control Protocol has a separate set of
Configuration Options. These permit the negotiation of
the following items:
o Sequenced Delivery
o Reset on Loss
o Maximum Received Reconstructed Unit
o Maximum Received Completed Sequence (Prior to Loss)
9.1. Sequenced Delivery Option
Figure 3: Sequenced Delivery Option
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type=1 | length = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| On = 1 Off = 0|
+-+-+-+-+-+-+-+-+
This option requests the system at the other end of the link
not to deliver packets out of sequence. In the absence of
reliable delivery over member links, a missing fragment
would delay the release of any completed packet following it
until the implementation unambiguously determined that the
Sklower [Page 8]
Draft Internet Multilink August 1993
fragment had been lost, such as in the procedure described
in section 8 above.
[Ed Note: It has been suggested that the number of outstand-
ing incomplete packets, or the number of fragments or the
total number of bytes should be negotiatiable. Certainly,
one can calculate the minimum number ammount of space
required based on slippage, round trip times, and the number
of links in the group.]
The Default value is ``Sequencing Not Required''.
9.2. Reset on Loss
Figure 4: Reset on Loss Option
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type=2 | length = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| On = 1 Off = 0|
+-+-+-+-+-+-+-+-+
This option requests the system at the other end of the link
to, upon detection of the loss of a fragment, re-enter the
multilink-control-negotiation phase.
The Default value is ``Don't Reset on Loss''.
9.3. Maximum Receive Reconstructed Unit
Figure 5: Maximum Receive Reconstructed Unit Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type=3 | length = 4 | Maximum-Receive-Rebuilt-Unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This option advises the peer that the implementation will be
able to reconstruct a datagram consisting of the specified
number of bytes.
The default value is 8192 bytes.
Note: this option controls the MRU of the logical (group)
link, and could be negotiated by and LCP options exchange
inside multilink packets. Having a protocol option at the
MCP allows it to be piggy-backed onto other MCP options.
Sklower [Page 9]
Draft Internet Multilink August 1993
9.4. Maximum Received Completed Sequence
Figure 5: Maximum Received Sequence Number
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type=4 | length = 4 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This option is used after an implementation reenters MCP
after suspecting a fragment loss. The sequence number is
that of the last complete datagram successfully reassembled
prior to the detection of the loss.
10. Synchronization
When sequenced delivery is in effect, there are issues about
signaling loss, and graceful termination of a constituent
link among several in a group, if it has been determined
that the additional bandwidth is no longer needed.
We propose a mechanism that can be use for both purposes.
Any time that MCP has been successfully completed, on any
constituent link, an implementation may send a MCP configu-
ration request including the ``Maximum Received Sequence''
(MRS) option. The implementation must not send any further
multilink packets until both sides have sent and received
configure-ack packets control packets.
Upon receipt of a config-request with a MRS option, the peer
implementation must eventually reply with either a config-
request including the MRS option, or a config-ack. The peer
may also delay send the ack up to twice the round trip delay
time. The peer MUST NOT begin transmitting multilink pack-
ets over the constituent link until the initiating implemen-
tation sends a config-ack. Both the implementation and its
peer MAY continue sending traffic on the other participating
links in the group however.
When permitted to resume sending packets, an implementation
may (re-)transmit a packet with a lower sequence than was
last transmitted prior to re-entry into the MCP on that mem-
ber link, provided that the window sizes and quantities M
are known to both systems, such that the packet cannot be
interpreted as sequence space wrap after an extensive loss.
If the constituent link is to be closed, each peer may send
terminate-request packets after verifying that all fragments
transmitted prior to dropping back into control protocol
mode had been received.
Sklower [Page 10]
Draft Internet Multilink August 1993
11. Default State of the Group Link
In order to minimize the number of packet exchanges in
establishing a multilink group, and in order to minimize the
amount of overhead in using the logical (group) link, when
use of the Multilink Protocol is negotiated, the following
defaults are assumed for the bundle (logical group link):
o No async control character Map
o No Magic Number
o No Link Quality Monitoring
o Address and Control Field Compression
o Protocol Field Compression
o Maximum Receive Unit of 8192
Thus, after the first link in a bundle concludes the MCP
negotiation, a (logical) group link is identified between
the authenticated identities, and is declared already to be
in the PPP open state with the above defaults listed, but
with no network level protocols negotiated. If the above
defaults are unsatisfactory, LCP config requests packets
could be sent embeded in multilink packets, and the bundle
(logical group link) would fall out of the open state. If
the above states were acceptible, then no further exchange
of LCP packets over the bundle would be required.
So long as any member links in the bundle are active, the
PPP state for the bundle persists as a separate entity.
12. Interaction with Other Protocols
In the common case, LCP, Authentication CP, and the Multi-
link Control Protocol would be run over each member link.
The Network Protocols themselves and associated control
exchanges would normally be run on the bundle, and given a
suitable choice of defaults for the bundle (as stated in the
previous section), no further LCP exchanges over the bundle
should be necessary.
In some instances it may be desireable for some Network Pro-
tocols to be exempted from sequencing requirements, and if
the MRU sizes of the link did not cause fragmentation, those
protocols could be negotiated directly over the member
links.
If there were several member links between two implementa-
tions and independent sequencing of two protocol sets was
desired, but blocking of one by the other was not, one could
describe two multilink procedures by assigning multiple
authentication names to the same systems. Each member link,
however, would only belong to one bundle.
Sklower [Page 11]
Draft Internet Multilink August 1993
The following table may help clarify common practice:
Table 1. Where Packet Types Are Carried.
On Member Links On the Bundle
_________________________________________
LCP (R) NP/NCP_a (R)
Multilink CP (R) Compression (C)
Authentication NCP (A)
Link Quality NCP (H)
LAPB (H)
Compression (C)
NCP/NP_b (E)
_________________________________________
Notes:
(R) Required. (If there are no network nor bridged proto-
cols nor compression packets carried, why bother with
multilink?)
(A) Authentication is waived for reliable out-of-band nam-
ing.
(C) Compression may be done on the constituent links or on
the bundle. Running compression over the bundle may
ease memory requirements. Compression usually requires
reliable link operation. We indicate the desire to run
a common compression accross links by placing the CCP
packets after multilink headers.
(H) These procedures are helpful in the case of compres-
sion, but not necessarily required.
(E) This case is unusual, but permitted, and could be used
to exempt traffic from sequencing requirements.
13. References
[1] Leifer, D., Sheldon, S., and Gorsline B., "A Subnetwork
Control Protocol for ISDN Circuit-Switching" IPLPDN
Working Group, Internet Draft (Expired), March 1991.
[2] Simpson, W., "The Point-to-Point Protocol (PPP) for the
Transmission of Multi-protocol Datagrams over Point-to-
Point Links", Network Working Group, RFC-1331, May
1992.
[3] Lloyd, B., Simpson, W., "PPP Authentication Protocols",
Networking Working Group, RFC-1334
Sklower [Page 12]
Draft Internet Multilink August 1993
[4] Bradley, T., Brown, C., and Malis, A., "Multiprotocol
Interconnect over Frame Relay", Network Working Group,
RFC-1294, January 1992.
[5] Malis, A., Robinson, D., Ullman R., "Multiprotocol
Interconnect on X.25 and ISDN in the Packet Mode", Net-
work Working Group, RFC-1356, August 1992.
[6] Internation Organisation for Standardization, "HDLC -
Description of the X.25 LAPB-Compatible DTE Data Link
Procedures", Internation Standard 7776, 1988
[7] Simpson, W., ``PPP over Frame Relay'', Networking Work-
ing Group, work in progress.
[8] Simpson, W., ``PPP over X.25'', Networking Working
Group, work in progress.
14. Author's Address
Keith Sklower
Computer Science Department
570 Evans Hall
University of California
Berkeley, CA 94720
Phone: (510) 642-9587
E-mail: sklower@cs.Berkeley.EDU
15. Expiration Date of this Draft
February 15th, 1994
Sklower [Page 13]